home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1206.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  2.1 KB  |  49 lines
  1. Tony Sanders writes (Sun, 23 May 1993)
  2.  
  3. > What are you browser writers thinking about supporting wrt HTTP/1.0 request
  4. > headers (e.g., see the kerberos proposal below)?  We need to think about
  5. > how to implement the ChargeTo: and Authorization: headers in a generic
  6. > way so the browser can easily support different styles.  I would
  7. > like to see From:, User-Agent:, and Referer: being used (currently
  8. > I've only seen "Accept: text/plain" and "Authorization: user xxx").
  9.  
  10. I am successfully using the Authorization field within Hewlett Packard
  11. for providing restricted access to Web documents:
  12.  
  13. Two formats:
  14.  
  15.     a)  Authorization: user fred:secret
  16.     b)  Authorization: user fred
  17.  
  18. When the browser gets error code 401 (unauthorized) it asks the user
  19. for a username and password. This is then included as (a) in all subsequent
  20. queries to the same server (same protocol, port and host name). By default
  21. the browser always sends the user name as (b) which it obtains from the
  22. environment variable "USER". This avoid the need for users to type
  23. anything if they are known to the server via the .rhosts or /etc/hosts.equiv
  24. mechanism.
  25.  
  26. This approach matches our needs well, and corresponds to the standard level of
  27. security offered with FTP, rlogin and telnet. Its really great to see someone
  28. extending this to support Kerberos!
  29.  
  30. I have also been studying the privacy enhanced mail proposals and the general
  31. field of authentication and encryption based on public key techniques. These
  32. techniques require the setup of registration authorities that permit you to
  33. look up the public key for any person on the system.
  34.  
  35. Such an approach would allow servers to use the registered public key of a
  36. client to check that a request indeed originated from that client.
  37. Furthermore it would allow clients to be certain that a document obtained
  38. from a server is indeed by whom it claims to be and hasn't been altered in
  39. anyway whatsoever.
  40.  
  41. To do this we will need to define authentication formats for both HTRQ
  42. and MIME headers. This needs to be done in concert with other groups in
  43. the Internet. Is anyone interested in picking this up?
  44.  
  45. Regards,
  46.  
  47. Dave Raggett
  48.  
  49.